home *** CD-ROM | disk | FTP | other *** search
/ Languguage OS 2 / Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO / language / arjuna / index < prev    next >
Text File  |  1994-10-23  |  28KB  |  644 lines
  1. Implementing Fault-Tolerant Distributed Applications Using Objects and
  2. Multi-Coloured Actions
  3.  
  4. Santosh K Shrivastava and Stuart M Wheater
  5.  
  6. Abstract
  7.  
  8. This paper develops some control structures suitable for composing
  9. fault-tolerant distributed applications using atomic actions (atomic
  10. transactions) as building blocks, and then goes on to describe how such
  11. structures may be implemented using the concept of multi-coloured
  12. actions. We first identify the reasons why other control structures in
  13. addition to - by now well known - nested and concurrent atomic actions
  14. are desirable and then propose three new structures:  serializing
  15. actions, glued actions and top-level independent actions. A number of
  16. examples are used to illustrate their usefulness. A novel technique,
  17. based on the concept of multi-coloured actions, is then presented as a
  18. uniform basis for implementing all of the three action structures
  19. presented here.
  20.  
  21.  
  22. Location:    /pub/Arjuna/Papers/Multi-Coloured-Actions_EuropeA4.ps.Z
  23.         /pub/Arjuna/Papers/Multi-Coloured-Actions_USLetter.ps.Z
  24.  
  25. ---------------------------------------------------------------------
  26.  
  27. An Overview of the Arjuna Distributed Programming System
  28.  
  29. Santosh K Shrivastava, Graeme N Dixon and Graham D Parrington
  30.  
  31. Abstract
  32.  
  33. Arjuna is an object-oriented programming system which provides a set of
  34. tools for constructing fault-tolerant distributed applications. Arjuna
  35. supports nested atomic actions (nested atomic transactions) for
  36. structuring programs. Programs invoke operations on objects which are
  37. instances of abstract data types. In Arjuna, objects are long lived
  38. entities (persistent) and are the main repositories for holding system
  39. state. By ensuring that objects are only manipulated within an atomic
  40. action, it can be guaranteed that the integrity of objects (and hence
  41. the integrity of the system) is maintained in the presence of failures
  42. such as node crashes and the loss of network messages. A number of
  43. mechanisms are required to achieve fault tolerance and to provide
  44. distribution. This paper gives an overview of these mechanisms, which
  45. have been implemented in the language C++, and describes how they
  46. support the object model of computation employed by Arjuna.
  47.  
  48.  
  49. Location:    /pub/Arjuna/Papers/Overview-Of-Arjuna_EuropeA4.ps.Z
  50.         /pub/Arjuna/Papers/Overview-Of-Arjuna_USLetter.ps.Z
  51.  
  52. ---------------------------------------------------------------------
  53.  
  54. Exploiting Type Inheritance Facilities to Implement Recoverability in
  55. Object Based Systems
  56.  
  57. G.N. Dixon and S.K. Shrivastava
  58.  
  59. Abstract
  60.  
  61. One of the key concepts available in many object based programming
  62. languages is that of type inheritance, permitting new object types to
  63. be refined out of existing object types.  This paper discusses how this
  64. concept can be exploited for introducing recoverability into a system.
  65. A multilevel object based recovery model is employed, permitting
  66. recoverable objects to be constructed out of recoverable and
  67. unrecoverable objects.  Simple examples are used to illustrate the
  68. ideas and to demonstrate the suitability of the proposed approach.
  69.  
  70.  
  71. Location:    /pub/Arjuna/Papers/Type-Inheritence_EuropeA4.ps.Z
  72.         /pub/Arjuna/Papers/Type-Inheritence_USLetter.ps.Z
  73.  
  74. ---------------------------------------------------------------------
  75.  
  76. Implementing Concurrency Control in Reliable Distributed
  77. Object-Oriented Systems
  78.  
  79. Graham D. Parrington and Santosh K. Shrivastava
  80.  
  81. Abstract
  82.  
  83. One of the key concepts available in many object-oriented programming
  84. languages is that of type-inheritance, which permits new types to be
  85. derived from, and inherit the capabilities of, old types.  This paper
  86. describes how to exploit this property in a very simple fashion to
  87. implement object-oriented concurrency control.  We show how by using
  88. type-inheritance, objects may control their own level of concurrency in
  89. a type-specific manner.  Simple examples demonstrate the applicability
  90. of the approach. The implementation technique described here is being
  91. used to develop Arjuna, a fault-tolerant distributed programming system
  92. supporting atomic actions.
  93.  
  94.  
  95. Location:    /pub/Arjuna/Papers/Concurrency-Control_EuropeA4.ps.Z
  96.         /pub/Arjuna/Papers/Concurrency-Control_USLetter.ps.Z
  97.  
  98.  
  99. ---------------------------------------------------------------------
  100.  
  101. The Treatment of Persistent Objects in Arjuna
  102.  
  103. Graeme N. Dixon, Graham D. Parrington, Santosh K. Shrivastava and
  104. Stuart M. Wheater
  105.  
  106. Abstract
  107.  
  108. Arjuna is a programming system which provides a set of tools for
  109. constructing fault-tolerant distributed applications.  It supports an
  110. object-oriented model of computation in which atomic actions (atomic
  111. transactions) control sequences of operations invoked upon persistent
  112. objects.  Persistent objects outlive the applications that create them
  113. and this paper concentrates on the mechanisms within Arjuna that are
  114. concerned with their management.  The paper describes how these
  115. mechanisms are related to the other Arjuna mechanisms required by
  116. atomic actions for the distribution, concurrency control, recovery and
  117. commitment of persistent objects.
  118.  
  119.  
  120. Location:    /pub/Arjuna/Papers/Treatment_of_Persistence_EuropeA4.ps.Z
  121.         /pub/Arjuna/Papers/Treatment_of_Persistence_USLetter.ps.Z
  122.  
  123. ---------------------------------------------------------------------
  124.  
  125. Replicated K-Resilient Objects in Arjuna
  126.  
  127. Mark C Little and Santosh K Shrivastava
  128.  
  129. Abstract
  130.  
  131. This paper describes the design of an object replication scheme for the
  132. Arjuna distributed system. The design supports K-resiliency, where, in
  133. the absence of network partitions, K out of a total of K+1 replica
  134. failures can be tolerated before an object becomes unavailable. The
  135. scheme chosen employs active replication where each and every
  136. functioning replica of an object carries out processing.  Computations
  137. are structured as atomic actions (atomic transactions). The paper
  138. presents the details of how object groups are created and terminated,
  139. how a group can be invoked and object replicas inserted and removed in
  140. a consistent manner in the presence of node failures.
  141.  
  142.  
  143. Location:    /pub/Arjuna/Papers/Replicated-Objects_EuropeA4.ps.Z
  144.         /pub/Arjuna/Papers/Replicated-Objects_USLetter.ps.Z
  145.  
  146.  
  147. ---------------------------------------------------------------------
  148.  
  149. Maintaining Information about Persistent Replicated Objects in a
  150. Distributed System
  151.  
  152. M.C. Little, D.L. McCue and S.K. Shrivastava
  153.  
  154. Abstract
  155.  
  156. The paper presents a general model for persistent replicated object
  157. management and identifies what meta information about objects needs to
  158. be maintained by a naming and binding service to ensure that objects
  159. named by application programs are bound to only those object replicas
  160. which are in a mutually consistent state. These ideas are developed
  161. within the framework of a distributed system  in which application
  162. programs  are composed of atomic actions (atomic transactions)
  163. manipulating persistent (long-lived) objects.
  164.  
  165.  
  166. Location:    /pub/Arjuna/Papers/NamingAndBinding_EuropeA4.ps.Z
  167.         /pub/Arjuna/Papers/NamingAndBinding_USLetter.ps.Z
  168.  
  169.  
  170. ---------------------------------------------------------------------
  171.  
  172. Computing Replica Placement in Distributed Systems
  173.  
  174. Daniel McCue and Mark Little
  175.  
  176. Abstract
  177.  
  178. We have been investigating the design of a replica management system
  179. (RMS) which allows a programmer to specify the quality of service
  180. required for individual replicated objects in terms of availability and
  181. performance. From the quality of service specification, information
  182. about the replication protocol to be used, and data about the
  183. characteristics of the underlying distributed system, the RMS computes
  184. an initial placement and replication level for the replicated object.
  185. As machines and communications systems are detected to have failed or
  186. recovered, the RMS can be re-invoked to compute an updated mapping of
  187. replicas which preserves the desired quality of service.
  188.  
  189.  
  190. Location:    /pub/Arjuna/Papers/ReplicaPlacement_EuropeA4.ps.Z
  191.         /pub/Arjuna/Papers/ReplicaPlacement_USLetter.ps.Z
  192.  
  193.  
  194. ---------------------------------------------------------------------
  195.  
  196. Understanding Component Failures and Replication in Distributed Systems.
  197.  
  198. S. K. Shrivastava, P. Ezhilchelvan and M. Little
  199.  
  200. Abstract
  201.  
  202. Faults are causes of system failures. The function of a fault-tolerant
  203. algorithm of a system is to attempt to tolerate the failures of the
  204. system's components so that the system can continue to provide
  205. specified system services. The design of such an algorithm for any
  206. given system function requires making fault models of components so
  207. that the assumed behaviour of faulty components can be stated
  208. precisely. We present a fault and failure classification for components
  209. using expected value and timeliness as the two properties of a
  210. component's response.  This classification helps the development of
  211. fault models of components and also the design of fault-tolerant
  212. algorithms capable of tolerating faults - from relatively restricted
  213. ones to increasingly more general ones. We show how the fault
  214. classification can be extended to apply to replicated systems.
  215.  
  216.  
  217. Location:    /pub/Arjuna/Papers/ISA-Report_EuropeA4.tar.Z
  218.         /pub/Arjuna/Papers/ISA-Report_USLetter.tar.Z
  219.  
  220.  
  221. ---------------------------------------------------------------------
  222.  
  223. Structuring Persistent Object Systems for Portability in a Distributed
  224. Environment
  225.  
  226. Daniel L. McCue
  227. Santosh K. Shrivastava
  228.  
  229. Abstract
  230.  
  231. The object-oriented approach to system structuring has found widespread
  232. acceptance among designers and implementers of robust distributed
  233. information processing systems.  In such systems, state information is
  234. held within objects which may reside in object stores.  Furthermore, if
  235. any changes to the state of the system are performed under the control
  236. of atomic actions (atomic transactions), then it can be ensured that no
  237. inconsistencies are introduced despite applications making conflicting
  238. accesses to objects and the occurrence of common failures (such as node
  239. crashes).  Previous attempts to design a portable applications
  240. programming environment have focussed on heterogeneous RPC facilities
  241. and common run-time environments.  Where portable RPC and common
  242. run-time efforts have already provided some level of access and
  243. location transparency, we have raised the level of portable,
  244. object-oriented applications development to include persistence,
  245. concurrency control, recoverability, replication and migration of
  246. objects.  In this paper we look at  distributed programming systems
  247. supporting persistent objects and examine key portability features such
  248. a system should possess.  Major system components and their interfaces
  249. are identified.  An existing system is examined to verify the
  250. feasability of the proposed architecture.
  251.  
  252.  
  253. Location:    /pub/Arjuna/Papers/Structuring-For-Portability_EuropeA4.ps.Z
  254.         /pub/Arjuna/Papers/Structuring-For-Portability_USLetter.ps.Z
  255.  
  256.  
  257. ---------------------------------------------------------------------
  258.  
  259. Structuring Fault-Tolerant Object Systems for Modularity in a
  260. Distributed Environment
  261.  
  262. Santosh K. Shrivastava and Daniel L. McCue
  263.  
  264. Abstract
  265.  
  266. The object-oriented approach to system structuring has found widespread
  267. acceptance among designers and developers of robust computing systems.
  268. In this paper we propose a system structure for distributed programming
  269. systems that support persistent objects and describe how such
  270. properties as persistence, recoverability etc. can be implemented. The
  271. proposed structure is modular, permitting easy exploitation of any
  272. distributed computing facilities provided by the underlying system. An
  273. existing system constructed according to the principles espoused here
  274. is examined to illustrate the practical utility of the proposed
  275. approach to system structuring.
  276.  
  277.  
  278. Location:    /pub/Arjuna/Papers/Modularity_EuropeA4.ps.Z
  279.         /pub/Arjuna/Papers/Modularity_USLetter.ps.Z
  280.  
  281.  
  282. Technical Report Number 414 (February 1993)
  283.  
  284. ---------------------------------------------------------------------
  285.  
  286. Programming Distributed Applications Transparently in C++: Myth or
  287. Reality?
  288.  
  289. Graham D. Parrington
  290.  
  291. Abstract
  292.  
  293. Modern   computing  and   networking  hardware   make   the   physical
  294. interconnection  of  many  machines simple.  However,  programming  an
  295. application to take even limited  advantage  of the interconnection is
  296. notoriously difficult due to the complexity of the protocols involved.
  297. Furthermore, real world demands insist that such applications need  to
  298. be programmed in an existing,  preferably  widely available, language.
  299. One approach aimed at easing this difficulty is based upon the concept
  300. of transparency.  By making the underlying distribution of  the system
  301. transparent to the programmer  it is hoped  that the  programming task
  302. becomes comparable with that of  programming centralised applications.
  303. This paper  describes  mechanisms and tools  that  enable the  various
  304. facets of transparency can be accomplished for the language C++ noting
  305. what level of transparency can be realistically attained.
  306.  
  307.  
  308. Location:    /pub/Arjuna/Papers/OpenForum92.ps.Z
  309.  
  310.  
  311.  
  312. ---------------------------------------------------------------------
  313.  
  314. Reliable Distributed Programming in C++: The Arjuna Approach
  315.  
  316. Graham D. Parrington
  317.  
  318. Abstract
  319.  
  320.     Programming in a  distributed system is fraught with potential
  321. difficulties caused,  in part,  by the  physical distribution  of  the
  322. system itself. By making the distribution of the system transparent it
  323. is hoped that the  task becomes comparable with that of  programming a
  324. more  traditional  centralised  system.   Object-oriented  programming
  325. systems  are natural starting points for  such an attempt  due to  the
  326. inherent modularisation  and  encapsulation properties  they  possess.
  327. Arjuna  is  one  such  system, programmed  in  C++, which  permits the
  328. construction  of reliable  distributed applications  in  a  relatively
  329. transparent manner.
  330.     Objects in Arjuna  can be located  anywhere in the distributed
  331. system  and  are  accessed  as  if  they  were  purely  local  to  the
  332. application.  The use of remote procedure calls  to perform the actual
  333. accesses is  hidden  by the  use  of stub generation  techniques which
  334. operate  on the original C++ class  descriptions thus  furthering  the
  335. illusion   of  transparency.   Reliability  is  achieved  through  the
  336. provision  of  traditional  atomic transaction  mechanisms implemented
  337. using only standard language features.
  338.  
  339.  
  340. Location:    /pub/Arjuna/Papers/UsenixC++90.ps.Z
  341.  
  342.  
  343. ---------------------------------------------------------------------
  344.  
  345. Configuring Distributed Applications using Object Decomposition in an
  346. Atomic Action Environment
  347.  
  348. Stuart M. Wheater and Daniel L. McCue
  349.  
  350. Abstract
  351.  
  352. A common technique for constructing reliable distributed applications
  353. is to use atomic actions for controlling operations on persistent
  354. objects.  Atomic actions are used to ensure that inconsistencies in
  355. application state do not arise when failures occur or when concurrent
  356. activities operate on shared objects.  Within such an application,
  357. objects provide a convenient unit for distribution and
  358. concurrency-control.  The properties of atomic actions and objects can
  359. be exploited together to configure distributed applications, without
  360. affecting the correct functioning of the application.  This leads to
  361. the possibility of changing the configuration of concurrency and
  362. distribution of the distributed application to improve availability and
  363. performance.  These changes in concurrency and distribution can be
  364. achieved by varying the object decomposition within the application.
  365. In this paper, we show how some kinds of re-configuration can be
  366. achieved without any modification to client applications.  The
  367. observations are
  368.  
  369.  
  370. Location:    /pub/Arjuna/Papers/Reconfiguration_EuropeA4.ps.Z
  371.         /pub/Arjuna/Papers/Reconfiguration_USLetter.ps.Z
  372.  
  373. ---------------------------------------------------------------------
  374.  
  375. Object Replication in Arjuna
  376.  
  377. Mark C Little and Santosh K Shrivastava
  378.  
  379. DRAFT: August 1993
  380.  
  381. Abstract
  382.  
  383. Arjuna is a fault tolerant distributed system supporting nested atomic
  384. actions (nested atomic transactions) that are used for controlling
  385. operations on objects (instances of C++ classes). Objects are long
  386. lived entities (persistent) and are the main repositories for holding
  387. system state; they are also the units of replication for increasing
  388. availability. This paper describes the design and implementation of two
  389. object replication schemes for Arjuna. Support for replication is
  390. provided by a naming and binding service for persistent replicated
  391. objects that ensures that applications only ever get to use mutually
  392. consistent copies of replicas.
  393.  
  394.  
  395. Location:    /pub/Arjuna/Papers/ObjectReplication_EuropeA4.ps.Z
  396.         /pub/Arjuna/Papers/ObjectReplication_USLetter.ps.Z
  397.  
  398.  
  399. ---------------------------------------------------------------------
  400.  
  401. The Replica Management System: a Scheme for Flexible and Dynamic
  402. Replication
  403.  
  404. M. C. Little and D. L. McCue
  405.  
  406. Abstract
  407.  
  408. The actual gains achieved by replication are a complex function of the
  409. number of replicas, the placement of those replicas, the replication
  410. protocol, the nature of the transactions performed on the replicas, and
  411. the availability and performance characteristics of the machines and
  412. networks composing the system. This paper describes the design and
  413. implementation of the Replica Management System, which allows a
  414. programmer to specify the quality of service required for replica
  415. groups in terms of availability and performance. From the quality of
  416. service specification, information about the replication protocol to be
  417. used, and data about the characteristics of the underlying distributed
  418. system, the RMS computes an initial placement and replication level. As
  419. machines and communications systems are detected to have failed or
  420. recovered, or performance characteristics change, the RMS can be
  421. re-invoked to compute an updated mapping of replicas which preserves
  422. the desired quality of service. The result is a flexible, dynamic and
  423. dependable replication system.
  424.  
  425.  
  426. Location:    /pub/Arjuna/Papers/ReplicaManagement_EuropeA4.ps.Z
  427.         /pub/Arjuna/Papers/ReplicaManagement_USLetter.ps.Z
  428.  
  429.  
  430. ---------------------------------------------------------------------
  431.  
  432. Exercising Application Specific Run-time Control Over Clustering of
  433. Objects
  434.  
  435. Stuart  M Wheater and Santosh Shrivastava
  436.  
  437. Abstract
  438.  
  439. Support  for  dynamic  reconfiguration   permitting  changes  to   the
  440. structure of an application while it is in  operation is becoming more
  441. and  more important  for  distributed applications.  One use of such a
  442. reconfiguration facility would be to dynamically change the  structure
  443. of an application in  order to improve its performance. In this  paper
  444. we  describe the design and implementation  of a  dynamic  performance
  445. improvement  scheme   that  is  based  on  controlling  clustering  of
  446. persistent  objects.   Our  scheme  provides  a means  of  dynamically
  447. reconfiguring storage  structures  of  application  objects,  from  no
  448. clustering (all objects treated as independent), to maximum clustering
  449. (all objects grouped together), including  any  intermediate level  of
  450. clustering, to suit a given pattern of usage.
  451.  
  452.  
  453. Location:    /pub/Arjuna/Papers/ObjectClustering_EuropeA4.ps.Z
  454.         /pub/Arjuna/Papers/ObjectClustering_USLetter.ps.Z
  455.  
  456.  
  457. ---------------------------------------------------------------------
  458.  
  459. Stabilis:   A  Case   Study  in   Writing  Fault-Tolerant  Distributed
  460. Applications Using Persistent Objects
  461.  
  462. L.E.Buzato and A.Calsavara
  463.  
  464. Abstract
  465.  
  466. This   paper  presents  Stabilis,   a  fault-tolerant  object-oriented
  467. distributed database management system  that  has  been  written as an
  468. exercise in persistent programming. Stabilis is implemented on top  of
  469. Arjuna, an object-oriented  programming system that provides the basic
  470. mechanisms for  fault tolerance  and distribution.   The computational
  471. model used by Arjuna is based upon the concept of using atomic actions
  472. to control  operations  upon  persistent  objects.   Stabilis aims  at
  473. experimenting  with  Arjuna  to  build  large  applications  that  use
  474. persistent objects. Such  experiment has led us to extend some of  the
  475. mechanisms  for  persistent  programming already  existent  in Arjuna.
  476. Stabilis  manages objects that  are persistent, recoverable and can be
  477. accessed remotely and  concurrently  in a consistent  manner.  Objects
  478. with  such properties  have  an  important  function  in  the  overall
  479. operation of  Stabilis.  The database manager can  be  operated either
  480. through  a visual database  interface or  a  query  interpreter;  both
  481. translate  commands into  a  series  of  operations  of  the  database
  482. manager.  All operations of the database  manager make  use of  atomic
  483. actions and  locks  to  structure and  control accesses to objects.  A
  484. flexible use of nested atomic actions permits objects to retrogress to
  485. previous consistent  states. Stabilis  has  been developed using  C++;
  486. dispensing  with the use  of  any  specifically designed language  for
  487. persistent programming.
  488.  
  489.  
  490. Location:    /pub/Arjuna/Papers/Stabilis_EuropeA4.ps.Z
  491.         /pub/Arjuna/Papers/Stabilis_USLetter.ps.Z
  492.  
  493.  
  494. ---------------------------------------------------------------------
  495.  
  496. Objects and Actions in Reliable Distributed Systems
  497.  
  498. S.K. Shrivastava, G.N. Dixon, and G.D. Parrington
  499.  
  500. Abstract
  501.  
  502. This paper describes a method for constructing robust distributed
  503. programs. The method is based upon the provision of atomic actions that
  504. operate upon objects (instances of abstract data types).  We begin by
  505. constructing robust non-distributed programs using the atomic action
  506. mechanism and then proceed to show how robust distributed programs can
  507. be constructed in a similar fashion.Finally we briefly examine other
  508. prototype distributed systems and examine their approach to the
  509. reliability problem.
  510.  
  511. This paper is a revised and extended version of Chapter 6, "Robust
  512. Distributed Programs" taken from the book "Resilient Computing
  513. Systems", ed. T. Anderson, Collins, 1985.
  514.  
  515.  
  516. Location:    /pub/Arjuna/Papers/ObjectsAndActions_EuropeA4.ps.Z
  517.         /pub/Arjuna/Papers/ObjectsAndActions_USLetter.ps.Z
  518.  
  519.  
  520. ---------------------------------------------------------------------
  521.  
  522. Constructing Reliable Distributed Applications Using Actions And
  523. Objects
  524.  
  525. Stuart M. Wheater
  526.  
  527. Abstract
  528.  
  529. A computation model for distributed systems which has found widespread
  530. acceptance is that of atomic actions (atomic transactions) controlling
  531. operations on persistent objects. Much current research work is
  532. oriented towards the design and implementation of distributed systems
  533. supporting such an object and action model. However, little work has
  534. been done to investigate the suitability of such a model for building
  535. reliable distributed systems. Atomic actions have many properties which
  536. are desirable when constructing reliable distributed applications, but
  537. these same properties can also prove to be obstructive.
  538.  
  539. This thesis examines the suitability of atomic actions for building
  540. reliable distributed applications. Several new structuring techniques
  541. are proposed, providing more flexibility than hitherto possible for
  542. building a large class of applications. The proposed new structuring
  543. techniques are: Serialising Actions, Top-Level Independent Actions,
  544. N-Level Independent Actions, Common Actions and Glued Actions.
  545.  
  546. A new generic form of action is also proposed, the Coloured Action,
  547. which provides more control over concurrency and recovery than
  548. traditional actions. It will be shown that Coloured Actions provide a
  549. uniform mechanism for implementing most of the new structuring
  550. techniques, and at the same time are no harder to implement than normal
  551. actions. Thus this proposal is of practical importance.
  552.  
  553. The suitability of the new structuring techniques will be demonstrated
  554. by considering a number of applications. It will be shown that the
  555. proposed techniques provide natural tools for composing distributed
  556. applications.
  557.  
  558.  
  559. Location:    /pub/Arjuna/Theses/TR-316-6-90_EuropeA4.tar.Z
  560.         /pub/Arjuna/Theses/TR-316-6-90_USLetter.tar.Z
  561.  
  562.  
  563. ---------------------------------------------------------------------
  564.  
  565. Object Replication in a Distributed System
  566.  
  567. Mark C. Little
  568.  
  569. Abstract
  570.  
  571. A number of techniques have been proposed for the construction of
  572. fault-tolerant applications. One of these techniques is to replicate
  573. vital system resources so that if one copy fails sufficient copies may
  574. still remain operational to allow the application to continue to
  575. function. Interactions with replicated resources are inherently more
  576. complex than non-replicated interactions, and hence some form of
  577. replication transparency is necessary. This may be achieved by
  578. employing replica consistency protocols to mask replica failures and
  579. maintain consistency of state between functioning replicas.
  580.  
  581. To achieve consistency between replicas it is necessary to ensure that
  582. all replicas receive the same set of messages in the same order,
  583. despite failures at the senders and receivers. This can be accomplished
  584. by making use of order preserving reliable communication protocols.
  585. However, we shall show how it can be more efficient to use unordered
  586. reliable communication and to impose ordering at the application level,
  587. by making use of syntactic knowledge of the application.
  588.  
  589. This thesis develops techniques for replicating objects: in general
  590. this is harder than replicating data, as objects (which can contain
  591. data) can contain calls on other objects. Handling replicated objects
  592. is essentially the same as handling replicated computations, and
  593. presents more problems than simply replicating data. We shall use the
  594. concept of the object to provide transparent replication to users: a
  595. user will interact with only a single object interface which hides the
  596. fact that the object is actually replicated.
  597.  
  598. The main aspects of the replication scheme presented in this thesis
  599. have been fully implemented and tested. This includes the design and
  600. implementation of a replicated object invocation protocol and the
  601. algorithms which ensure that (replicated) atomic actions can manipulate
  602. replicated objects.
  603.  
  604.  
  605. Location:    /pub/Arjuna/Theses/TR-376-9-91_EuropeA4.tar.Z
  606.         /pub/Arjuna/Theses/TR-376-9-91_USLetter.tar.Z
  607.  
  608.  
  609. ---------------------------------------------------------------------
  610.  
  611. Selective Transparency in Distributed Transaction Processing
  612.  
  613. Daniel L. McCue
  614.  
  615. Abstract
  616.  
  617. Object-oriented programming languages provide a powerful interface for
  618. programmers to access the mechanisms necessary for reliable distributed
  619. computing.  Using inheritance and polymorphism provided by the object
  620. model, it is possible to develop a hierarchy of classes to capture the
  621. semantics and inter-relationships of various levels of functionality
  622. required for distributed transaction processing.
  623.  
  624. Using multiple inheritance, application developers can selectively
  625. apply transaction properties to suit the requirements of the
  626. application objects.
  627.  
  628. In addition to the specific problems of (distributed) transaction
  629. processing in an environment of persistent objects, there is a need for
  630. a unified framework, or architecture in which to place this system.  To
  631. be truly effective, not only the transaction manager, but the entire
  632. transaction support environment must be described, designed and
  633. implemented in terms of objects.
  634.  
  635. This thesis presents an architecture for reliable distributed
  636. processing in which the management of persistence, provision of
  637. transaction properties (e.g., concurrency control), and organisation of
  638. support services (e.g., RPC) are all gathered into a unified design
  639. based on the object model.
  640.  
  641.  
  642. Location:    /pub/Arjuna/Theses/TR-390-8-92_EuropeA4.tar.Z
  643.         /pub/Arjuna/Theses/TR-390-8-92_USLetter.tar.Z
  644.